As has been known for a long time, Internet Protocol v. 4 (IPv4) is rather limited in terms of available address space. To address the issue, standard RFC1918 defines three networks intended for private use, namely 10.0.0.0 (Class A), 172.16.0.0 (Class B) and 192.168.0.0 (Class C). None of these private networks have been routed to the public internet. Large corporations and service providers typically have Class A network (10.0.0.0) address space to expand the address space available to them, while ADSL and cable modems commonly used in homes and small offices distribute IP addresses from private 192.168 networks. Connections to the outside world are provided by utilizing Network Address Translation (NAT) technology, wherein a NAT device located between the public and private networks acts as a bridge. Since several private networks share the same 10.0.0.0 address space, they are overlapping. Overlap has been an insignificant problem as long as these private networks have been run internally, instead of routing them to the public internet.
Overlapping of private networks becomes a problem in connection with cloud computing, or cloud-based services. For instance, IaaS (Infrastructure as a Service) service providers are increasingly deploying multi-tenant computing environments used to offer services concurrently to several business clients, all of whom may use the same 10.0.0.0 address space especially in the context of Virtual Private Cloud and/or other similar technologies. In use-cases such as this, the private networks used by different tenants typically overlap.
In the following description, “orchestration” is used in its established meaning within Service Oriented Architecture (“SON”) realm, when discussing automated workflows between data processing and communication systems. Enterprises and service providers use orchestration solutions to align business requests with the applications, data and infrastructure. The said solutions are typically used to define the policies and service levels through automated workflows, provisioning, and change management. With this technology, organizations are able to create an application-aligned infrastructure that can be scaled up, down or sideways based on the needs of each application. Orchestration also provides centralized management of the resource pool, including billing, metering, and chargeback for consumption.
Allocation of IP addresses, names and other network parameters to the various servers, commonly referred to as workloads, which execute applications in orchestrated environments, has traditionally been accomplished by configuring an IP address in the said servers and by adding the server's name with the corresponding IP address to a domain name server (DNS) manually, or by having such allocation performed dynamically using Dynamic Host Configuration Protocol (DHCP) and dynamic DNS. Since the IP addresses and the names of the physical servers run in traditional orchestrated computing environments have been relatively static, their SOA-based automated workflow management processes have not been extended to integrate with IP and name commissioning mechanisms. As existing orchestration solutions are expanded to cloud-based computing environments, the traditional methods used to manage IP addresses and names described above will create various problems. For instance, as cloud-based computing paradigm requires that new virtual machines are provisioned on demand, the manual IP and name assignment process associated with the prior art methods used for allocation IP resources and names in traditional orchestrated computing environments quickly become a bottleneck as far as the scalability of the entire cloud-based computing environment is concerned. In addition, although the cloud-based on-demand computing paradigm requires that the life-cycle of a virtual server instance can be anywhere from minutes to several years, DHCP servers provide a predefined and fixed lease time for the automatically assigned IP addresses, thereby making it impossible to align the IP lease times with the dynamic nature of the virtual computing environment. Furthermore, the prior art techniques make it impossible to automatically reclaim an IP address when a virtual machine is decommissioned, as even with DHCP, the decommissioning is tied to the pre-defined lease time of the IP addresses that have been issued. The prior art methods thus make it impossible to align the lease time of an IP address with the unique life-cycle of each virtual machine run within the cloud.
Limitations of DHCP are quickly revealed by attempting to use in connection with cloud computing. One of the reasons for the poor compatibility between DHCP and cloud computing is that DHCP was never designed for cloud computing or web-based integration models. For instance, DHCP operates on OSI Layer 2 (L2). In practice, a client sends a broadcast message to a local-area network (LAN). A DHCP server in that LAN captures the broadcast message, inspects the client's Medium Access Control (MAC) address, which is a unique address of the network interface adapter, and returns an IP address with other network parameters to the MAC address. After that the client configures the network parameters for itself and is able to adopt a TCP/IP connection, which operates on higher OSI layers.
In practice, the above-described methodology requires that the client and the DHCP server must be interconnected by an L2 connection. In practice, the client and the DHCP server must be connected to the same LAN network. The LAN may be comprised of multiple VLAN networks, but these must be interconnected on L2 layer. In cases where clients have overlapping 10.0.0.0 address spaces, the service provider must isolate them from one another by configuring the overlapping address spaces into distinct LAN networks. As a result, all private networks are isolated from one another, which enables IP traffic within the network on one hand and prevents clients from accessing the networks of other clients.
A consequence of the facts that, firstly, DHCP operates on L2 and, secondly, overlapping address spaces must be isolated into separate LANs, is that a single DHCP cannot logically reside in multiple LANs separately. In other words, in the case of multiple private networks, each of them must have a dedicated DHCP server.
Internet Protocol version 6 (IPv6) provides two mechanisms for dynamic IP allocations. These mechanisms are called Stateful autoconfiguration and Stateless autoconfiguration. Neither autoconfiguration mechanism solves the above-identified problems because, firstly, stateful autoconfiguration (DHCPv6) is not really any different from DHCPv4 used in IPv4 environments. This is because each time an IP resource is allocated to a virtual machine, the allocated IP resource obtains a fixed lease value, which basically means that the IP resource shall remain allocated for a predefined period of time, regardless of whether or not the allocated IP resource actually continues to be utilized by the virtual machine. Within cloud-based environments, this is undesirable, because the IP addresses should be commissioned (issued) whenever a new virtual machine goes live, and (released) whenever that virtual machine is removed from the virtualized computing environment.
On the other hand, stateless autoconfiguration means that a client autonomously obtains an IP address on the basis of router advertisements. As far as SOA architectures and orchestration are concerned, there are two reasons why this scheme may not work. First, in environments where orchestration is used, it is a typical requirement that the IP address is obtained from a network that matches the Virtual Local Area Network (VLAN) in which a virtual machine is intended to run. In other words, the IP address has to be allocated from a specific network corresponding to the VLAN in which the virtual machine is to be deployed, instead of giving the virtual machine an arbitrary IP address that happens to be available (the latter is what stateless autoconfiguration leads to). The second reason why stateless autoconfiguration may not work in this use case is that the environments are typically multi-tenant environments where the administrator has to be able to actively monitor allocation levels of each network and determine what equipments and clients are being run in the networks. In the event that the IP addresses are obtained autonomously by the clients, there is no way to control the IP addresses which a given virtual machine will have obtained, nor will there be any transparency to this process that would allow the administrator to manage these relationships and/or track the allocation of IP allocations.
Commonly-owned patent application US20130346618 proposes solutions to the above-identified problems, by teaching techniques that allow multiple orchestrators (servers running orchestration solution) to obtain network parameters from a single authoritative source called IP commissioning/decommissioning server (=“IPCDS”). The method taught in the commonly owned application can be used to provision network parameters from both elastic and traditionally switched networks so long as the networks have been recorded in the IPCDS system.
After deployment of the techniques proposed by the US20130346618 application, a number of related problems have been identified. For instance, TCP/IP networks are moving towards elastic architectures and process automation through technologies such as Software-Defined Networking (SDN). Benefits provided by such technologies include increased service agility through automated management and configuration processes, enhanced security through methodologies such as micro-segmentation, as well as service agility introduced by integration with automated service workflows and processes run by orchestrators responsible for deploying virtualized workloads and services, converged infrastructure, containers, or the like.
In many cases, however, SDN is not deployed in pure greenfield environments. Rather, SDN is often used to create networks inside network blocks that also contain traditionally switched networks based on the traditional TCP/IP networking model that dates back to the 1980s. Therefore, organizations that intend to use SDN must make sure that the new elastic networks and microsegments do not overlap with the traditional networks that have already been activated inside the same public IPv4 blocks, private IPv4 blocks and/or public IPv6 blocks (together, “shared network blocks”).
As cloud stacks and SDN controllers typically allow free network prefixes to be manually configured into them, they are able to automatically assign networks from the prefixes that have been configured into them. However, a common source of problem is that the aforementioned technologies are not aware of the overall allocation status of the shared network blocks to which the said network prefixes belong. This makes service automation problematic in use cases such as Software-Defined Wide Area Networking (SD-WAN) or Network-as-a-Service (NaaS) in which the free network prefix(es) to be used by the SDN controller should be automatically located, reserved and/or assigned into the SDN controller as part of the service automation workflow.
Furthermore, when provisioning network parameters to one or more orchestrators responsible for deploying virtualized (network) services and workloads, converged infrastructure, containers or the like, it is required that the network parameters relating to both the elastic networks and the traditional networks are being provisioned from a single authoritative source (IPCDS), as the aforementioned resources connecting to the network are unaware of the method by which the underlying TCP/IP network has been set up. This enables orchestrated processes that are independent of the technologies that have been used to deploy the underlying TCP/IP networks.
To partially solve the problem, commonly-owned patent application publication US20130346618 teaches a method that allows multiple orchestrators to obtain network parameters from a single authoritative source (IPCDS). The method taught in the said application can be used to provision network parameters from both elastic and traditionally switched networks so long as the networks have been recorded in the IPCDS system. This typically requires manual deployment of the networks that provide the IP resources managed by the IPCDS.
Accordingly, there is still room for improvements in incorporating the management, the assignment and the release of network blocks and/or their contents into service automation workflows, as well as in the management and the automated assignment and/or releasing of network blocks, network prefixes and the alike into one or more SDN controllers.